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History  of  the  Contract  Guidebook 


■  The  Naval  OA  Contract  Guidebook  for 
Program  Managers,  version  1 .0,  was 
released  on  05  July  2006. 

■  Since  that  time,  the  Guidebook  has  gone 
through  several  iterations  and  updates. 

■  In  2010,  as  part  of  his  “Better  Buying 
Power”  initiative,  USD  AT&L,  Ashton 
Carter  took  notice  of  the  Navy’s  OA 
Contract  Guidebook 

■  Dr.  Carter  recommended  elevating  the 
Contract  Guidebook  to  be  a  Joint,  DoD- 
level  publication. 

■  Intended  to  be  a  living  document,  the  next 
spiral  of  the  OSA  Contract  Guidebook  will 
incorporate  feedback,  lessons  learned  and 
best  practices  from  practitioners  across 
DoD’s  acquisition  community. 


NAVAL  OPEN 
ARCHITECTURE 
CONTRACT 
GUIDEBOOK 
FOR  PROGRAM 
iS^NAGERS 
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Introduction  to  the  DoD  OSA  Contract  Guidebook 


■  The  Guidebook  is  recommended  for  use  by  all  component  Service 
Program  Managers  and  Contracting  Officers. 

■  For  Programs  incorporating  OSA  principles  into  National  Security 
System  (NSS)  programs. 

■  The  recommended  language  should  be  tailored  based  on  Service, 
Domain,  PEO,  or  Program-specific  requirements. 

■  The  Guidebook  is  divided  into  six  chapters 
of  suggested  contract  language  for  Sections 
C,  H,  L,  and  M,  CLINs  and  Incentive  Plans. 

■  Additionally,  there  are  1 1  Appendices  on  various 
topics,  including  CDRLs,  intellectual  property 
rights,  peer  reviews,  system  specification 
language  and  breaking  vendor  lock. 


Distribution  Statement  B  -  Distrtxrtion  authorized  to  U.S.  DoO  Contract  Guidebook  v.1 .0 

Government  agencies  onty;  Other  requests  must  be  referred  to  October  20, 201 1  DRAFT 
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Recommendations  for  Section  C  Language 


Section  C  of  the  Request  for  Proposal  (RFP)  and  the  resulting  contract 
contains  the  detailed  description  of  the  products  to  be  delivered  or  the  work  to 
be  performed  under  the  contract.  Recommended  OSA  language  for  Section 
C  covers  topics  such  as: 


Open  architecture 

Modular,  open  design 
System  requirements  accountability 
Inter-component  dependencies 
Modular  Open  Systems  Approach 
Design  information  documentation 
Technology  insertion 
Life  Cycle  Sustainability 


Interface  design  and  management 

Treatment  of  proprietary  elements 

Open  business  practices 

Reuse  of  pre-existing  or  common  items 

Third-Party  Development 

Life  Cycle  Management  and  Open  Systems 

Standards 


Sample  Language 


“Open  Business  Practices  -  The  contractor  shall  demonstrate  that  the 
modularity  of  the  system  design  promotes  the  identification  of  multiple  sources 
of  supply  and/or  repair,  and  supports  flexible  business  strategies  that  enhance 
subcontractor  competition.” 
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Recommendations  for  Section  H  Language 


Section  H  of  the  RFP  and  the  resulting  contract  contains  special  clauses  that 
can  be  incorporated  into  contracts  as  appropriate.  Recommended  Section  H 
clauses  for  OSA  contracts  include: 


■  Requirement  for  an  Open  System  Management  Plan 
Early  and  Often  Technical  Disclosure 

Rights  in  Commercial  Technical  Data  (TD),  Commercial  Computer  Software 
(CS),  and  Commercial  Computer  Software  Documentation  (CSD) 

■  Specially  Negotiated  License  Rights 

■  Special  Provisions  for  the  Purpose  of  Configuration  Control 
Special  Development  Limitation  Provisions 


Sample  Language 

“Clause  H:  Requirement  for  an  Open  System  Management  Plan. 

The  contractor  shall  submit  an  Open  System  Management  Plan.  At  minimum,  the  plan  shall  address: 

Technical  Approach  and  Processes 

Open  Systems  Approach  and  Goals.  The  contractor  shall  prepare  and  submit  for  government 
approval  its  Open  System  Management  Plan  which  shall  include  its  approach  for  using  ...” 
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Recommendations  for  Section  L  Language 


Section  L  of  the  RFP  provides  proposal  instructions,  conditions  and  notices  to 
Offerors.  Offerors  should  be  encouraged  to  clearly  demonstrate,  through  their 
use  of  similar  technologies  previously  developed,  the  ability  to  meet  the  design, 
development,  testing,  and  production  requirements  of  the  solicitation. 

Recommended  OSA  language  for  Section  L  addresses: 

■  Technical  Approach  and  Processes 

■  System  Compliance  with  DoD  or  Service  OSA  Guidance 

■  Management  Approach 

■  Data  Rights  and  Patent  Rights 

■  OSA  Past  Performance 

Sample  Language 


“Factor  ( )  Data  Rights  and  Patent  Rights  . . . 

The  Offeror  shall  describe  its  plan  for  making  design  and  interface  information  available 
as  soon  as  possible  after  it  is  defined  or  established.  The  Offeror  shall  establish  and 
maintain  a  process  that  will  provide  ‘early  and  often’  design  disclosure  directly  to  the 
Government  or  to  third-party  contracts.” 
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Recommendations  for  Section  M  Language 

Section  M  contains  only  recommended  guidance  for  evaluation  factors  for 
contract  award.  Individual  PEOs  and  programs  can  be  flexible  in  selecting  and 
weighting  those  items  needed  to  meet  their  needs.  Recommended  Section  M 
evaluation  factors  for  award  of  OSA  contracts  include: 

□  Open  Systems  Approach  and  Goals 

□  Interface  Design  and  Management 

□  Treatment  of  Proprietary  or  Vendor-Unique  Elements 

□  Life  Cycle  Management  and  Open  Systems 

■  System  Compliance  with  DoD/Component  Service  OSA  Guidance 

■  Management  Approach 

■  Data  Rights,  Computer  Software  Rights  and  Patent  Rights 


Sample  Language 


“Factor  ()  Management  Approach: 

The  Offeror  shall  describe  its  approach  for  using  Integrated  Product  Teams  (IPTs)  to  improve  processes, 
proactively  manage  risk  and  increase  efficiency.  The  Offeror  shall  describe  the  steps  it  shall  take  to  educate 
IPT  members  and  others  involved  in  the  project  on  the  importance  and  principles  of  OSA.” 
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Recommendations  for  Incentivizing 
Contractors _ 

Award  Fee,  Incentive  Fee,  and  Award  Term  plans  can  be  used  by  programs  to 
incentivize  and  award  contractors  for  implementing  Open  Systems  Architecture 
principles. 

Incentive  plans  can  be  used  to  award  contractors  for: 

■  Incorporating  considerations  for  portability,  maintainability,  technology 
insertion,  vendor  independence,  and  reusability 

■  Implementing  a  layered  and  modular  system 

■  Minimizing  inter-component  dependencies 

■  Collaborating  with  the  Government  and  other  contractors  and  vendors 

■  Reducing  development  cycle  time 

■  Using  open,  standards  based  interfaces 

■  Enabling  rapid  technology  insertion 


Award  Terms  -  Instead  of  rewarding  contractors  with  additional  fees  for 
exceptional  performance,  award  term  contracts  reward  contractors  by 
extending  the  contract  period  of  performance  in  the  form  of  additional  term 
periods  added  on  to  the  basic  contract. 


November  9,  201 1 


Page  8 


Open  Architecture  ...Changing  the  Way  We  Do  Business  Today! 


Appendices  to  the  Guidebook 


Appendix  1:  RECOMMENDED  CDRL  AND  DELIVERABLE  ITEMS 
Appendix  2:  OSA  CHECKLIST  (short) 

Appendix  3:  OSA  CHECKLIST  (long) 

Appendix  4:  RECOMMENDED  DATA  LANGUAGE  FOR  CODE  HEADERS 
Appendix  5:  OPEN  SOURCE  SOFTWARE 
Appendix  6:  GLOSSARY  OF  TERMS 

Appendix  7:  ASSESSING  A  PROGRAM’S  INTELLECTUAL  PROPERTY  RIGHTS 
NEEDS  AND  DEVELOPING  A  DATA  RIGHTS  STRATEGY  (DRS) 

Appendix  8:  CLICKWRAP  OR  EMBEDDED  LICENSE  ISSUES 

Appendix  9:  BETTER  BUYING  POWER:  UNDERSTANDING  AND  LEVRAGING 

DATA  RIGHTS  IN  DoD  ACQUISITIONS 

Appendix  10:  BREAKING  and  AVOIDING  VENDOR  LOCK 

Appendix  11 :  SAMPLE  CONTRACT  DATA  REQUIREMENTS  LISTS  (CDRLs) 
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TSppendix  1: 
Items 


Recommended  OSA  CDRL  and  Deliverable 


■  The  Guidebook  provides  examples  of  Contract  Data  Requirements 
List  (CDRL)  and  other  deliverable  items  that  support  OSA,  facilitate 
component  reuse,  and  can  be  incorporated  into  contracts 

■  Examples: 

□  Reuse  Management  Report 

□  Open  Systems  Management  Plan 

□  Software  Design  Description 

□  Software  Development  Plan 

□  Interface  Design  Description 

□  Data  Accession  List 

□  Detailed  Specification  Documents 


This  is  an  area  of  considerable  interest  and  one  that  we  are  working  to 
continually  improve  as  our  knowledge  improves 
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Appendices  2  &  3:  The  OSA  Checklists 

■  Developed  by  the  Navy’s  OAET  to  facilitate  the  implementation  of 
OSA  and  to  provide  PMs,  PEOs,  and  the  Milestone  Decision 
Authority  an  easy  way  to  check  to  see  that  programs  are 
implementing  the  main  points  of  OSA 

■  The  short  checklist  is  intended  to  be  a  quick  check  on  a  system’ s 
programmatics  that  when  properly  applied  will  yield  the  benefits  of 
an  open  system 

■  The  Checklist  of  Required  FARs  and  DFARs  clauses  provides  a 
complete  references  of  those  clauses  which  are  applicable  to 
OSA 

■  The  long  version  of  the  checklist  is  divided  up  consistent  with  the 
OSA  principles  laid  out  previously  in  the  contract  guidebook 
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Appendix  4:  Recommended  Data  Language  for  Code 
Headers 


■  Deliverable  artifacts  should  include  embedded  data  or  language 
in  code  headers  or  in  other  locations  that  provides  key  information 
for  those  seeking  to  use  these  items  in  the  future 

■  Appendix  4  includes  recommendations  for  such  language 

■  Developed  by  the  Navy’s  SPAWAR 

■  The  following  are  suggestions  that  can  be  used  as  appropriate  for 
artifacts  delivered  under  the  various  types  of  licensing  rights: 

□  Unlimited  Rights 

□  Government  Purpose  Rights  (GPR) 

□  Specially  Negotiated  License  Rights. 
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Appendix  5:  Open  Source  Software  (OSS) 


■  The  terms  “open  source”  and  “open  architecture’  are  often 
confused  and  at  times  are  incorrectly  used  interchangeably, 
however,  they  are  distinct 

■  Open  Source  Software  (OSS)  presents  the  Government  with 
unique  challenges  with  respect  to  some  OSS  licensing 
requirements 

■  This  Appendix  explains  issues  to  consider  when  using  OSS,  such 
as  the  inability  to  negotiate  license  terms  and  “viral”  licenses 
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Appendix  6:  Glossary  of  Terms 


■  Provides  a  glossary  of  all  terms  used  throughout  the  course  of  the 
contract  guidebook 

■  Includes  source  references  (where  available) 

■  Example  terms  defined  include: 

□  Artifact 

□  Commercial  item 

□  Design  disclosure 

□  Firmware 

□  Government  Purpose  Rights  (GPR) 
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Appendix  7:  Assessing  Intellectual  Property  Rights 
Needs  and  Developing  a  Data  Rights  Strategy  (DRS) 


■  Consistent  with  Under  Secretary  of  Defense  (Acquisition,  Technology  and 
Logistics)  Memorandum  on  Data  Management  and  Technical  Data  Rights, 19 
July  2007,  directing  programs  to  take  steps  to  identify  and  manage  their 
Intellectual  Property  Rights  (IPR) 

■  Contains  pointers  on  the  questions  that  a  data  rights  assessment  should 
answer 

■  Identifies  process  for  developing  a  Data  Rights  Strategy 

■  Discusses  points  to  consider  about  data  rights  and  rights  in  computer 
software  and  computer  software  documentation 

■  Cites  sections  of  the  Federal  Acquisition  Regulations  (FAR)  and  Defense 
Federal  Acquisition  Regulation  Supplement  (DFARS)  that  provide 
information  about  IPR 
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Appendix  8:  Clickwrap  or  Embedded  License  Issues 


■  The  proposed  contract  language  presented  in  this  appendix  is  relates 
to  copyright,  licenses,  or  other  restrictions  included  in  delivered 
software. 

■  This  appendix  addresses  software  that  is  delivered  by  a  contractor  on 
a  website. 

■  Many  times  these  sites  contain  a  user’s  consent  to  all  the  terms  and 
conditions  of  the  site,  etc. 

■  Specifically  this  section  includes: 

□  Language  to  prevent  contractor  use  of  “Clickwrap”  licenses  to 
circumvent  government  purpose  rights. 
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Appendix  9:  Better  Buying  Power:  Understanding  and  Leveraging 
IP  Rights  in  DoD  Acquisitions 
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Appendix  9:  Better  Buying  Power:  Understanding  and 
Leveraging  IP  Rights  in  DoD  Acquisitions 


“Data  Rights”  Rights  Hi  Technical  Data  (TD) 
and  Computer  Software  {CS} 

“Data  Rights"  is  a  shorthand  way  to  refer  to  the 
Government’s  license  rights  in  two  major  categories  of 
valuable  intellectual  property: 

*  Technical  Data  (TD}  includes  any  recorded 
information  of  a  scientific  or  technical  nature 
(e.g„,  product  design  or  maintenance  data, 
computer  databases,  and  computer  software 
documentation  (GSID)).. 

*  Computer  software  (CS)  includes  executable  code, 
source  code,  code  listings,  design  details,, 
processes,  flow  charts,  and  related  material. 

Anticipating  the  Need  for  Data  and  Data  Rights 

A  Program  Manager  must  ensure  that  all  TD  and  CS 
and  related  license  rights  required  for  procurement 
and  sustainment  of  a  system  are  available  throughout 
the  system’s  life  cycle. 

*  Sustainment  activities  include  reprocurement, 
maintenance,  repair,  modifications  or  interfacing/ 
interoperability  activities,  and  upgrades  or 
technology  insertion. 

*  Consider  a  Priced  Option  for  any  data  deliverables 
or  data  rights  that  you  may  need  in  the  future,  but 
did  not  order  up  front. 

Identify  and  Resolve  Data  and  Data  Rights  Issues 
Prior  to  Contract  Award 

Identify  and  resolve  data  delivery  or  data  rights  issues 
prior  to  contract  award,  by: 

*  Requiring  Offerors  to  assert  all  restrictions  on 
deliverable  TD  and  CS  —  both  commercial  and 
noncommercial  —  up  front,  in  their  proposals; 

*  Evaluating  the  data  and  data  rights  packages  being 
offered ; 

*  Negotiating  for  mutually  agreeable  specialized 
license  rights  whenever  the  standard  license 
categories  do  not  meet  both  parties’  needs;  and 

*  Challenging  asserted  restrictions  if  necessary 
to  account  for  Government  investments. 


Data  Delivery  Requirements 

The  DFARS  clauses  do  not  require  delivery  of  TD  or  CS  —  the  Government  must  include  specif ic  delivery  requirements 
in  each  contract.  For  TD,  it  is  important  to  distinguish  detailed  design  data  from  less  detailed  operation  or 
maintenance  data.  For  GS.  it  is  important  to  distinguish  executable  code  from  source  code  and  other  design  data. 
Consider  a  priced  option  for  contingency-based  data  delivery  or  data  rights  needs. 

Data  Rights  Granted  to  the  Government 

The  Government’s  license  rights  to  a  contractor's  TD  and  CS  generally  depend  upon  the  extent  to  which  the 
Government  funded  the  development  of  the  technology,  whether  the  technology  is  commercial  or  noncommercial, 
and  any  negotiations  for  mutually  agreeable  “special”  license  agreements.  Some  types  of  data  qualify  for  Unlimited 
Rights  regardless  of  development  funding,  such  as  “form,  fit,  arid  function  data,"  (FFF)  and  data  necessary  for 
operation,  maintenance,  installation,  and  training  (OMIT)  purposes. 


Rights 

Category 

Applies  to 

These  Types  of  TD  or  CS 

Rights  Criteria 

Permitted  Uses  Within 
the  Cevemment 

Permitted  Uses  by 

ThEnd  Parties  Outside 
the  Government1 

Unlimited  Rights  (UR) 

Noncommercial  TD  and  CS 

Developed  exclusively  at 
Government  expense,  and 
certain  types  of  data  (e.g., 

FFR  OMIT.  CSD) 

Ail  uses;  no  restrictions 

All  uses;  no  restrictions 

Government  Purpose  Rights 
(GPHJ 

Noncommercial  TD  and  CS 

Developed  with  mixed  fu  nding 

All  uses;  no  restrictions 

For  ‘"Government  Purposes'- 
only:  no  commercial  use 

Limited  Rights  (LR) 

Noncommercial  TD  only 

Developed  exclusively  at 
private  expense 

Unlimited;  except  may  not 
be  used  for  manufacture 

Emergency  repair  or 
oveirhauF 

Restricted  Rights  (HR) 

Noncommercial  CS  only 

Developed  exclusively  at 
private  expense 

Only  one  computer  at  a 
time:  minimum  backup 
copies;  modification3 

Emergency  repair.'overhaul: 
certain  service/maintenance 
contracts? 

Negotiated  License  Rights 

Any/all  TD  and  CS- 
including  commercial  TD 
and  CS 

Mutual  agreement  of  the 
parties;  use  whenever  the 
standard  categories  do  not 
meet  both  parties7  needs 

As  negotiated  by  the  parties ;  however,  must  not  be  less  than 
LR  in  TD  and  must  not  be  less  than  RR  in  noncommercial 

CS  (consult  with  legal  counsel  as  other  limits  apply) 

SBIR  Dala  Rights 

Noncommercial  TD  and  CS 

AJITD  or  CS  generated  under 
an  SBI R  contract 

Affl  uses;  no  restrictions 

Cannot  release  or  disclose 
except  to  Government 
support  contractors 

Commercial  TO  License 
Rights 

Commercial!  TD  only 

TD  related  to  commercial  items 
(developed  at  private  expense) 

Unlimited  in  FFF  and  OMIT;  other  rights  as  negotiated 

Commercial  CS  Licenses 

Commercial  CS  only 

Any  commercial  CS  or  CS 
documentation 

As  specified  in  the  commercial  license  customarily  offered  to 
the  public4 

:  AB  tried  party  use  utter  tfte  Qavemma?fs  license  is  subject  to  Government  authorization.  For  rijfits  categories  other  that  UR.  releases  or  disefosues  to  third  parties  mist  be 
accompanied  by  ether  the  Non-Oisa'osure  Agreement  fNQA}  tom  OF.ARS  227.  rt  03-7  or. must  occur  under  a  contract  ccntairing  OFARS  252227-7025.  A  reo'co  segiirement  dso 
^jpties  to  releases  ofLR  data  and  RR software. 

3  tn  addition  to  the  footnote  t  NQA  ^d  notice  requiemants.  afi  authorized  Coveted  Gofontnort  Su^porf  Contractor  recipients  of  LR  data  or  RR  software  must  sign  an  fiOA  drectiy  with 
the  owner  of  the  datas’seftware.  uriess  the  drect-MDA  requirement  s  waived  by  the  owner. 

3  See  O  fA  RS  252227-7D  I4(a)(l5}  (March  20  ? }}  for  (a}( wj  in  previous  versims)  for  . more  information. 

4  Such  licenses  .musf  be  co.rstte.nt  with  Federal  procurement  law  and satisfy  user  needs. 
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Appendix  10:  Breaking  and  Avoiding  Vendor  Lock 


■  Provides  a  series  of  recommended  approaches  for  breaking  and 
avoiding  vendor  lock 

■  Directed  at  current  programs  who  are  vendor  locked 

■  Includes  case  study  examples  of  successfully  breaking/avoiding 
vendor  lock 

■  Approaches  to  breaking  and  avoiding  vendor  lock  addressed 
include: 

□  React  to  environment  and  create  a  crisis  for  change 

□  Leverage  and  exercise  data  rights 

□  Change  approach  to  systems  engineering 

□  Hold  competition 

□  Incentivize  good  behavior 

□  Change  contracts 
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^Appendix  1 1 :  Sample  Contract  Data  Requirements 
Lists 


■  This  appendix  includes  sample  CDRLs  that  can  be  used  in 
conjunction  with  Appendix  1  and  other  parts  of  the  guidebook  to 
define  the  project’s  deliverables  and  other  information  products. 

■  Selected  CDRLs  included  in  this  appendix  are: 

□  Scientific  and  Technical  Reports 

□  Interface  Control  Document  (ICD) 

□  Computer  Program  End  Item  Documentation 

□  Software  Development  Plan 

□  Software  Firmware  Transition  Plan 

□  Software  Requirements  Specification  (SRS) 

□  Interface  Requirements  Specification  (IRS) 

□  Software  Design  Description  (SDD) 

□  Others... 
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More  information  on  Open  Systems  Architecture  is  also 
available  on  the  Web  at  https://acc.dau.mil/oa 
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